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DESCRIPTION OF THE INVENTION 

Field of the Invention 

. 

| [001] This invention relates to Common Information Model (CM) environments and, 

\ { more particularly, to methods and systems for performing efficient association traversals. 

i 

!i Background of the Invention 

l ! 

[002] The Common Information Model (CIM) is a common data model of a schema 
I for describing the management of information in a network environment. The model is not 
,! bound to a particular implementation and enables distributed system management to take place 
ii between management systems and applications. The CIM enables applications to be built using 
: j management data from a plurality of management systems. 

' [003] A CIM typically consists of two parts, a CIM specification and a CIM schema. 

! The CIM specification describes the language, naming and mapping to other management 

, j 

i models, while the CIM schema provides the model descriptions. The CIM schema includes a set 
of classes with properties and associations that are used to organize information about a managed 
system. The CIM schema is separated into three layers: a core model; a common model; and an 
extension schema. 

[004] The core model contains a set of classes that are associated with a plurality of 
management domains. The common model is a model having a lower level than the core model, 
and provides base classes that are associated with certain management areas, yet not specific to a 
particular technology. The base classes allow for extensions into specific areas of technology. 
The extension schema defines technology specific extensions to the common model. 
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[005] The CIM is based on object-oriented modeling techniques. The Unified 
Modeling Language (UML) is generally used to construct an object oriented model. An 
exemplary model including UML representations is presented in Figure 1 . As shown, a class 
110 may have properties 120 and methods 130. Properties 120 are values used to represent 
certain characteristics of class 110, such as a unit of data. Methods 130 represent behavior 
characteristics of class 110. 

[006] Classes may be associated with subclasses that inherit characteristics from 
respective classes. As shown in Figure 1, subclasses 140 and 150 have a hierarchical 
relationship with class 1 10, represented by the link 115. Thus, subclasses 140 and 150 include 
the characteristics of class 110, with additional characteristics uniquely defined for each 
subclass. A relationship between objects in a hierarchical model may also be defined between 
peers, such as subclasses 140 and 150. Such a relationship is represented by an association in the 
CIM. An association is a class that comprises two or more references. References are basically 
pointers to other objects and define the role each object plays in an association. An association 
allows the CIM schema to establish a relationship between objects without affecting the objects 
themselves. As shown in Figure 1, an association 160 establishes a relationship between 
subclasses 140 and 150. The association 160 has two references. One reference 165 is directed 
to subclass 150, while another reference 167 is directed to subclass 140. 

[007] In the CIM model, only associations have knowledge of relationships between 
classes. With reference to Figure 1, only association 160 has knowledge that subclass 150 is 
related to subclass 140 via references 165 and 167, respectively. Subclasses 140 and 150, 
however, have no information indicating to either association 160 or subclass 150. Likewise, 
subclass 150 has no reference to either association 160 or subclass 140. 



j! [008] While Figure 1 illustrates subclasses dependent upon a base class, other objects 

! may be defined as well. For example, an instance may be defined that also inherits 

i 

! characteristics from an object it depends upon. An instance is a representation of a managed 

ij 

; object that belongs to a particular class, or occurrence of an event. That is, an instance of a class 
j, includes real data that relates to a real world managed object. For example, suppose class 110 
represents a class labeled CAR, and includes the inherent base characteristics for such a class. 

I 

! An instance of class 110 may represent, for example, a car driven by a particular driver. Another 
instance may represent a particular make of the car class 110. As described, objects such as 
instances are defined dynamically as the CIM schema grows. Each time an object is defined, any 
relationships between the newly object defined and existing objects are generally maintained in 

| the form of an association. 

| [009] While the use of associations introduces a method for relating objects, a problem 

| may occur when the relationship between the objects is requested by an application. In the CIM, 

j the link information for an association and its referenced objects is stored with the association 

i 

!j instance. That is, referring to Figure 1, references 165 and 167, which define the relationship 

ii 
ij 

i between subclasses 140, 150 and association 160, are located with association 160. Therefore, in 



r ~ | order to collect relationship information regarding subclasses 140 and 150, association 160 

i 

| would have to be examined (traversed). As a result, in order to determine if there is a 

s 

j relationship between any two or more objects, each instance of all associations defined in a CIM 

|| 

j schema would need to be examined to determine the existence of any related objects. 
! [010] In a conventional CIM schema, there is no way to recognize a relationship 

law off.ces ij between two or more instances that are "separated" by intermediate associations. As an 
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220 by an association 215. Instance 220 has a plurality of relationships with instances 230, 240 j 
and 250, represented by associations 222, 224 and 226, respectively. Instances 230, 240 and 250 

j 

each are separate instances of class 1, while associations 215, 222, 224 and 226 are separate I 

i 

instances of a class association A-l . In the conventional CIM schema depicted in Figure 2, in 
order to find the relationship between instance 210 and any of instances 230, 240 and 250, all 
associations 215, 222, 224 and 226 must be examined to identify the desired relationship. In the 
event a request to determine all instances associated with instance 210 is made (such as instances 
220, 230, 240 and 250), all associations related to instance 210 would have to be examined to 
determine which objects relate to instance 210. This technique is extremely inefficient, 
especially in a well established schema with a complex hierarchy. 



SUMMARY OF THE INVENTION 

[011] It is therefore desirable to provide a method and system that enable the 
relationship between objects in a CIM implemented system to be realized without having to 
traverse each instance of an association. 

[012] Methods, systems and articles of manufacture consistent with the present 
invention enable a CIM Object Manager (CIMOM) to create and store reverse links from an 
object to an association. The CIM Object Manager may then subsequently use the reverse links 
to efficiently determine the objects associated to a given input object, such as an instance of a 
class. 

[013] In accordance with an aspect of the invention, clients initiate requests to create 
classes and instances. The requests may be sent through a network to a server node that 
incorporates a CIM Object Manager that performs CIM object management functions. The CIM 



! Object Manager processes the requests, creates the classes and instances for each class, and 

j 

stores them in a CIM Object Manager repository. The CIM Object Manager creates wrappers for 
each instance of each class stored in the repository. The wrappers are accessible only by the 
| CIM Object Manager, and do not interfere with object definitions. The wrappers provide 
knowledge to a class instance outside the object definition itself, of what relationships it 
I participates in. In one aspect of the invention, the wrappers for each class instance point to a 
; second level table for each association class that references the class instance. The CIM Object 
| Manager defines association instances for each class instance that has a relationship with another 
| class instance. In addition to creating and storing association instances in the repository, the 
: CIM Object Manager creates references within each wrapper of a class instance. In another 
I aspect of the invention, the wrappers for each class instance point to a second level table that 
m \\ contains references directed to the association class instances that reference the class instance. 

\| ! [014] When the server node receives a client request for the relationship for a specific 

3 j instance of a class, the CIM Object Manager accesses the reverse links stored in the wrapper of 

£p ! 

"jf ! the instance associated with the request, or alternatively stored in the second level tables. The 

JJf ij CIM Object Manager uses the reverse links to determine the relationship between the requested 

r ~ instance, and any other associated objects. The server node then sends the relationship 

information to the client. 

i 
I 

!; [015] Accordingly, methods, systems and articles of manufacture consistent with the 

!| present invention enable association traversal requests to be handled without having to traverse 
I each instance of the associations defined in an object repository. 
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[016] Additional features of the invention will be set forth in part in the description 
which follows, and in part will be obvious from the description, or may be learned by practice of 
the invention. 



LAW OFFICES 

Finnegan, Henderson, 
Farabow, Garrett, 

% DtJNNER, L, L.P. 

1300 I STREET, N. W. 
WASHINGTON, DC 200 05 
202-408-4000 



BRIEF DESCRIPTION OF THE DRAWINGS 

[017] It is to be understood that both the foregoing general description and the 
following detailed description are exemplary and explanatory only and are not restrictive of the 
invention, as claimed. The accompanying drawings, which are incorporated in and constitute a 
part of this specification, illustrate several embodiments of the invention and together with the 
description, serve to explain the principles of the invention. In the drawings: 

[018] Figure 1 is a block diagram of an exemplary conventional object oriented model; 

[019] Figure 2 is a block diagram of an exemplary conventional CIM hierarchy; 

[020] Figure 3 is a block diagram of a CM based network, in accordance with 
methods and systems consistent with features of the present invention; 

[021] Figure 4 is a block diagram of the CIM Object Manager repository illustrated in 
Figure 3, in accordance with methods and systems consistent with features of the present 
invention; 

[022] Figure 5 A is a block diagram of an exemplary CIM hierarchy, in accordance 
with methods and systems consistent with features of the present invention; 

[023] Figure 5B is a block diagram of wrapper tables associated with the CIM 
hierarchy illustrated in Figure 5 A, in accordance with methods and systems consistent with 
features of the present invention; 

[024] Figure 5C is a block diagram of an exemplary CIM hierarchy, in accordance 
with methods and systems consistent with features of the present invention; 
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i [025] Figures 5D and 5E are block diagrams of wrapper tables associated with the 

CIM hierarchy illustrated in Figure 5C, in accordance with methods and systems consistent with 
features of the present invention; 
I [026] Figure 6A is a block diagram of an exemplary CIM hierarchy, in accordance 

! with methods and systems consistent with features of the present invention; 
j [027] Figure 6B is a block diagram of wrapper tables associated with the CM 

: hierarchy illustrated in Figure 6A, in accordance with methods and systems consistent with 
| features of the present invention; 

j [028] Figure 6C is another block diagram of wrapper tables associated with the CIM 

| 

! hierarchy illustrated in Figure 6A, in accordance with methods and systems consistent with 
| features of the present invention; 

! [029] Figure 6D is a block diagram of the exemplary CIM hierarchy shown in Figure 

! 6A when another instance is added to the hierarchy, in accordance with methods and systems 
| consistent with features of the present invention 

[030] Figure 6E is a block diagram of wrapper tables associated with the CIM 
hierarchy illustrated in Figure 6D, in accordance with methods and systems consistent with 
features of the present invention; 

[03 1] Figure 7 is an exemplary flow chart of a process performed by the CIM Object 
Manager associated with the creation of new instances, in accordance with methods and systems 
consistent with features of the present invention; and 

[032] Figure 8 is a flow chart showing association traversal operations, in accordance 
with methods and system consistent with features of the present invention. 
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DETAILED DESCRIPTION 

[033] The following description of embodiments of this invention refers to the 
accompanying drawings. Where appropriate, the same reference numbers in different drawings 
refer to the same or similar elements. 

[034] In accordance with an aspect of the present invention, clients initiate CM 
requests to create objects, generally, instances. The requests are received, via a network, at an 
object manager node incorporating a CIM Object Manager. The CIM Object Manager processes 
the requests and defines the objects stipulated in the client requests, and stores the definitions in 
a CM Object Manager repository. Wrappers are then created for each defined object, and also 
are stored in the repository. The CM Object Manager then defines associations related to the 
objects defined in the repository. For each association that is defined in the repository, the CM 
Object Manager creates a reverse link that shows a reverse reference from each object to its 
respective associations. Thus, when a client initiates a relationship request associated with a 
particular object, the CM Object Manager utilizes the reverse links to process the request. 

[035] The requests may be generated based on an operation defined by a Web Based 
Enterprise Management (WBEM) specification. WBEM is an initiative that provides standard 
based management tools for creating a compatible computing environment for technologies like 
CM and extensible Markup Language (XML). The requests may include a standard association 
traversal request. An Object Manager, among other standard management operations, also 
includes a predefined association traversal operation. This operation enables the Object Manager 
to traverse all associations of a given object. 

[036] Figure 3 shows an exemplary system implementing the CM association 
traversal techniques consistent with the present invention. As shown, the exemplary system 
comprises a Java™ Virtual Machine (JVM) 330, a network 310 and clients 320. JVM 330 



8 



!| further comprises a CM Object Manager 340 and repository 350. JVM 330 may operate on a 
; conventional computer system (not shown) such as an IBM PS/2 personal computer but is not 
limited to any particular system. JVM 330, may operate on any number of computer systems 

i 

1 1 such as network computers, workstations, and even mainframe computers having architectures 

1 1 

1 1 dissimilar to Figure 3. 

1 1 [037] A client 320 is a computer system that may use the Java™ programming 

| language and Java™ virtual machine architecture. A client 320 utilizes objects managed by 

! 

| JVM 330, by initiating requests, which may be facilitated through network 310. A client 320 
| may also initiate requests for the creation of new objects to be defined in repository 350. 
^ [038] JVM 330 is a microprocessor implemented in software that runs using the 

J! capabilities provided by an operating system and computer hardware associated with the 

||i i computer system that JVM 330 is implemented with. JVM 330 acts as an interpreter between 

%| ; Java™ bytecodes and the particular computer system (not shown) employing the JVM 330. 

£ I Bytecodes are compiled Java™ source code created using the Java™ programming language. 

2 :, The Java™ programming language is platform-independent, thus its utility is not bound to one 

*Ji ; particular platform (i.e., operating system and hardware). The advantages of a Java™ virtual 

machine architecture is that the virtual machine can be implemented in software in a variety of 
| operating systems and hardware. Implementing a JVM on a particular platform enables the 
! bytecodes to run without recompiling them. This is useful in a network that interconnects 
; heterogeneous systems, such as the Internet. 

[039] JVM 330 accepts requests from clients 320 for objects, including classes and 

LAW OFFICES ! instances, defined in repository 350. These requests are interpreted and managed by CIM Object 
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interaction between a client 320 and management applications. CIM Object Manager 340 
handles CIM based requests sent from clients 320, and manages repository 350. CIM Object 
Manager 340 defines classes, instances, associations, wrappers and reverse links. 

[040] Repository 350 is a storage area managed by CIM Object Manager 340. 
Repository 350 stores the definitions of classes, instances, associations, wrappers and reverse 
links created by CIM Object Manager 340. 

[041 ] Network 3 1 0 connects JVM 330 and clients 320, and may include one or more 
communication networks, including the Internet or any other similar network known in the art. 
Communication protocols used between elements connected to the network may be, but are not 
limited to XML, HTTP and TCP/IP. 

[042] Although Figure 3 shows a network interconnecting JVM 330 and clients 320, it 
is understood that clients 320 and JVM 330 may be implemented in common system 
environment that does not require a network for the exchange of information. Furthermore, 
clients may include processes operating within the common system environment. Additionally, 
it should be understood that features and principles of the present invention need not be 
implemented as depicted in Figure 3. That is, the repository 350 and Object Manager 340 shown 
in Figure 3, are exemplary and is not intended to be limiting. For example, the repository 350 
and object manager 340 need not be implemented with a virtual machine or a CIM environment, 
but may operate with other types of object-oriented processes that operate in a manner consistent 
with features and principles of the present invention. 

[043] Figure 4 shows an exemplary block diagram of repository 350. As shown, 
repository 350 contains a plurality of defined objects 420, 450. In Figure 4, the objects 
represented are instances 450A-450J of a first class defined in repository 350. Instances 420A 
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and 420B, for exemplary purposes, represent instances of a second class defined in repository 
350. Each instance may be associated with an association 430 that represents a relationship 
between objects. For example, instances 420A and instance 450A have an association 430-1 
\\ establishing a relationship between these two objects. Associations 430 are considered classes in 
I the CIM, and provide links 460 (represented as solid line arrows) to an object, such as instance 
i j 420 or instance 450. Each association class in turn may have instances defined as well. Thus, 
! the associations 430 shown in Figure 4, may represent instances of a single association class. 

! 

I! Links 460 point to instances and reflect a relationship between them. For example, instance 

j] 

ji 450A and instance 450F have a defined association 430-2 between them. Link 460-1 defines a 

j- reference from association 430-2 to instance 450A, and link 460-2 defines a reference from the 

i 

.j association 430-2 to instance 450F. Repository 350 also includes wrappers 410 for each 

!j 

j| instance, 420 and 450. Wrappers 410 are locally maintained tables that are specific to an 

is 
I 

ji instance it "wraps." As shown in Figure 4, each wrapper (depicted as the shaded area 
|! surrounding an instance) "wraps" around an instance 420 or instance 450. These wrappers may 
ji also be referred to as instance wrappers. Wrappers 410 will be described in further detail below 
with respect to Figures 5 A-5D and 6A-6E. 

[044] Each wrapper 410 defines reverse links 440 (represented as dotted line arrows) 
that provide references from each instance 420, 450 to a respective association instance 430. For 
example, in Figure 4, the association instance 430-1 shown between instances 420B and 420A 

i 

! receives reverse links 440-1, 440-2 that reference the relationships from instances 420B, 420A to 
; the association instance 430-1, respectively. It should be noted that the objects shown in Figure 

i 4 are exemplary, and any number of objects and hierarchical relationships may be defined in the 

j 

I repository by CIM Object Manager 340. 
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[045] CM Object Manager 340 establishes and manages the definitions of instances 
420, 450, associations instances 430, links 460, wrappers 410 and reverse links 440. Each time 
an instance is created in repository 350, CM Object Manager 340 generates associations 430 
based on the hierarchical relationship associated with each defined object. In turn, whenever an 
association is defined, CM Object Manager generates reverse links within each respective 
wrapper. Figures 5A-5D illustrate this process, in accordance with one aspect of the invention. 

[046] Figure 5A shows a CM model similar to that represented in Figure 2. That is, 
the model includes instances of various classes, represented by instances 510 (1-5), 520 (1-1), 530 
(1-2), 540 (1-3) and 550 (1-4), and associations 515 (A-l), 522 (A-2), 524 (A-3) and 526 (A-4). 
Also included in the model illustrated in Figure 5A, are wrappers associated with each instance. 
Specifically, instance wrapper 512 is associated with instance 510 (1-5), instance wrapper 523 is 
associated with instance 520 (1-1), instance wrapper 532 is associated with instance 530 (1-2), 
instance wrapper 542 is associated with instance 540 (1-3) and instance wrapper 552 is associated 
with instance 550 (1-4). The wrappers shown in Figure 5A are depicted in detail in Figure 5B. 

[047] Figure 5B shows repository 350 containing the wrappers, or wrapper tables, 
associated with each instance illustrated in Figure 5 A. As shown, instance 5 wrapper table is 
related to wrapper 512 in Figure 5 A, while the instance wrapper tables 1-4 correlate to the 
instance wrappers 523, 532, 542 and 552 in Figure 5A, respectively. Each wrapper table 
includes a reference to an association instance that has been defined for its respective instance, 
depending upon the representation of the wrapper. That is, instance 5 wrapper table is defined 
for instance 510 (1-5) in Figure 5 A, and any associations defined for that instance will be 
represented in its wrapper table. Instance 5 wrapper table includes association 515, labeled A-l, 
corresponding to the relationship depicted in Figure 5 A. Also included in each wrapper table are 

12 
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reverse links established for each relationship with the association listed in a respective wrapper. 
Again referring to the instance 5 wrapper table, and Figure 5 A, it can be seen that association A- 
1 defines a relationship between instance 1-5 of class 1 and instance 1-1 of class 2. Accordingly, 
instance 5 wrapper table also defines the relationship of association A-l with instance 1-1. As 
there are no other associations defined for instance 1-5, the remainder of its wrapper table is 
empty. 

[048] The remaining wrapper tables are similarly configured with information. 
Referring to instance 1 wrapper table and Figure 5 A, it can be seen that instance 1-1 has four 
association instances related to it, A-l through A-4. These are indicated in its wrapper table. 
Association instance A-l has references to instance 1-5, thus instance 1 wrapper table includes a 
reverse link that establishes this relationship. The same is true for the relationships between 
association instances A-2 through A-4. Instance 1 wrapper table includes the reverse links that 
show the relationship between each association instance and instances 1-2 through 1-4. 

[049] Instance wrappers are dynamically managed by CM Object Manager 340, in 
order to maintain an updated version of the hierarchical relationship of a CIM scheme. At any 
time, a client 320 may request the creation of additional objects. CIM Object Manager 340 
updates repository 350, and the wrappers for each affected instance, whenever a new association 
is defined. 

[050] Figure 7 shows an exemplary process performed by CIM Object Manager 340 
when a request to create a new instance is received from a client 320. A client 320 sends a 
request to create a new object, such as an instance of a particular class, over network 310 (Step 
710). The request may be performed using XML/HTTP protocols. For example, one client 320 
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initiate a request to create a new instance 1-6 of class 1 . Referring to Figure 5C, CM Object 
Manager 350 receives the requests and defines the new instance 1-7, and stores the definition in 
repository 350. CM Object Manager 340 then creates a wrapper for the newly defined instance 
(Step 720). A wrapper is created by creating a wrapper table for the new instance. In this case, a 
! new wrapper table for instance 7, would be created in repository 350. The new wrapper table 
I includes default fields to be filled relating to associations and reverse links correlated to these 

i j 

!| associations. Figure 5D shows repository 350 including newly defined wrappers, instance 6 
|, wrapper table and instance 7 wrapper table. 

I [05 1 ] CIM Obj ect Manager 340 defines an association instance 564 ( A-5) between 

i 

instance 1-5 and instance 1-7 (step 730), using the characteristics of new instance 1-7. Figure 5C 
illustrates the new association 564 (A-5), including its links pointing to instances 1-5 and 1-7. 
Once CBVI Object Manager 340 recognizes a newly defined association instance, it determines 
all objects the new association instance defines a relationship between, hi this case, association 
instance A-5 establishes a relationship between instances 1-5 and 1-7. Accordingly, CM Object 
Manager 340 defines reverse links within each instance's wrapper (Step 740). The reverse links 
are represented by the dotted lines pointing from wrappers 5 12 and 562 to association 564 (A-5) 
in Figure 5C. 

[052] Figure 5E illustrates how the wrappers in repository 350 are modified based on 
the created reverse links. The addition of newly defined instance 1-7, and association A-5 
! triggers CM Object Manager 340 to add the reverse links to the instance 5 wrapper table. As 
1 depicted, the instance 5 wrapper table includes a reverse link showing the relationship between 
; association A-5 and instance 1-7. Furthermore, newly defined wrapper table for instance 1-7 is 
F/ TSSXlT' il modified to include the relationship A-5 between instance 1-7 and instance 1-5. 
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I ! [053] The process for creating and maintaining the new instance wrapper for instance 

|i 1-6 in repository 350 is the same as that described for instance 1-7. That is, once CM Object 
1 Manager 340 defines an association instance A-6 between instances 1-6 and 1-4, a new wrapper 
I ; table for the new instance 1-6 is created in repository 350 and reverse links (depicted in Figure 
! 5C as dotted lines pointing from wrappers 552 and 572 to association A-6) are defined within 

i i 

: each instance's wrapper table. Referring to Figure 5E, the newly defined instance 6 wrapper 
jj table includes a reverse link showing the relationship between association instance A-6 and 
; instance 1-4. Furthermore, instance 4 wrapper table includes a reverse link showing the 
relationship between association instance A-6 and instance 1-6. 

[054] Accordingly, CM Object Manager 340 dynamically adjusts repository 350 with 
! ! new reverse links each time an instance of an association is created. This keeps repository 350 
;! updated with the most recent relationships for instances defined by CIM Object Manager 340. In 
l! keeping an updated status of these relationships enable association traversals to be performed 

| 

■ more efficiently by the CIM Object Manager 340. 

jj [055] Although the wrapper table structure described above, provides efficient 

ij 

jj association traversals, the structure is not rigid. That is, other wrapper structures may be 
; employed to provide traversal operations. In one aspect of the invention, the wrapper tables 
defined in repository 350, include pointers to secondary level association class wrapper tables, 
jj These secondary tables include each instance of a respective class association, and the reverse 
|; links to corresponding objects. Figures 6A-6E illustrate this aspect of the invention. 

[056] As shown, Figure 6A shows a CIM hierarchy similar to that represented in 

| Figure 5 A. However the model illustrated in Figure 6 A includes instances of several classes C-l 

Finnegan, Henderson, jj 
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of a first instance of class C-l is represented by instance 1-1 of class C-l (610), while instances I- 
1 of C-2, 1-2 of C-2 and 1-3 of C-2 (622, 624 and 626, respectively), reflect instances of a second 
class, C-2. Additionally, individual instances of a third and fourth class are shown by 1-1 of C-3 
(628), and 1-1 of C-4 (630). Instances 622-630 are each related to instance 610 through 
association instances of varying association classes 612, 614, 616, 618 and 620, respectively. 
Each association instance is an instance of an association class. As shown in Figure 6A, 
instances AC1-1, AC1-2 and AC1-3 are in association class AC1, instance AC2-1 is in 
association class AC2, and instance AC3-1 is in association class AC3. Although not shown in 
Figure 6A, a wrapper is associated with each respective class instance. These wrappers are 
described below with reference to Figure 6B. 

[057] Figure 6B represents a wrapper table defined in repository 350 associated with 
class instance 1-1 of C-l (610) illustrated in Figure 6A. As shown in Figure 6B, wrapper table 

| 632 includes a column 631 identifying association classes that have instances that are 

j 

' "associated" with instance 1-1 of C-l (610). Also, the wrapper table 632 includes a column 633 
identifying pointers to a second wrapper table corresponding to the association classes identified 

!: in column 631. For example, column 631 of wrapper table 632 contains identifiers for 
association classes AC1, AC2 and AC3, and column 633 includes pointers to second level tables 
for these association classes 644, 646 and 648, respectively. 

[058] Wrapper table 632 correlates to the relationship illustrated in Figure 6A, for 
instance 1-1 of C-l. Referring to Figure 6A, it can be seen that instance 1-1 of C-l (610) includes 
references to three different association classes AC1, AC2 and AC3. Although there are several 
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for instance (610) only includes pointers to the association classes, not to the instances of these 
association classes. 

[059] Referring back to Figure 6B, the second level tables 644, 646 and 648 that are 
referenced by column 633 include the appropriate association instances. As shown in Figure 6B, 
second level wrapper table AC-1 (644) includes pointers to each instance of association class 
AC1. Moreover, second level wrapper table 646 includes pointer to each instance of association 
class AC2, and second level wrapper table 648 includes pointer to each instance of association 
class AC3. 

[060] To further explain the features and principles of the present invention, Figure 6C 
shows the wrapper tables associated with instance 1-1 of C-3 and instance 1-1 of C-4. As with 
the wrapper tables depicted in Figure 6B, the wrapper tables illustrated in Figure 6C correspond 
to the hierarchy illustrated in Figure 6A. Particularly, Figure 6C shows a wrapper table 636 
including an identifier for association class AC2 and a pointer to a second level wrapper table 
650 corresponding to association class AC2. Second level wrapper table 650 includes a pointer 
to the instance of association class AC2-1 . Wrapper table 642 includes an identifier for 
association class AC3 and a pointer to second level wrapper table 660 corresponding to 
association class AC3. And, second level table 660 includes a pointer to association class 
instance AC3-1. 

[061] To illustrate the dynamic management of the wrapper table of this aspect of the 
invention, Figure 6D shows new instance objects 670 and 680 added to the CIM of Figure 6A. 
These new objects may be added using the same client request process described for the aspect 
of the present invention illustrated in Figures 5A-5E and 7. That is, a client 320 may initiate a 
request to create a new instance of class 5 (1-1 of C-5) in repository 350. Once CM object 
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manager 340 defines the new instance, an association instance is formed, based on the 
characteristics of instance 1-4 of C-5. In this case, an new association class instance AC4-1 of 
association class AC4 is defined, that relates instances 680 and 622. 

[062] After these objects are defined, a first level wrapper table for the affected class 
instances are modified to reflect the change to the CM shown in Figure 6D. As shown in Figure 
6E, the first level wrapper table 623 for class instance 622 is modified to reflect the new 
association class added to the CM of Figure 6D. Particularly, first level wrapper table 623 
includes identifiers 625 for association classes AC1 and AC4 corresponding to the association 
classes that include instances that are related to class instance 622. Also, the first level wrapper 
table 623 includes pointers to second level wrapper tables 627 and 629, that correspond to the 
association classes AC1 and AC4, respectively. Second level table 627 includes a pointer to 
association class instance AC 1-1, and second level table 629 includes a pointer to association 
class instance AC4-1. 

[063] As can be seen, methods and systems consistent with features of the present 
invention allow the first and second level wrapper tables to be used in order to maintain an 
updated "map" of all relationships between objects defined in repository 350. This allows 
specific object relationships to be efficiently provided when they are requested, by using known 
traversal methods and the defined wrapper tables. 

[064] Figure 8 illustrates an exemplary process performed when using second level 
wrapper tables to perform a traversal request, consistent with features and principles of the 
present invention. The process begins when a traversal request is received by CHM Object 
j Manager 340 to obtain association relations for a class instance (Step 810). Next, a defined first 
level wrapper table associated with the class instance designated in the request is located and 
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accessed (Step 820). Once located, the appropriate association classes reflected in the first level 
wrapper table are identified (Step 830). For each association class reflected in the first level 
wrapper table, a pointer corresponding to the association class is used to identify and locate the 
appropriate second level wrapper table (Step 840). Afterwards, the identified second level 
wrapper table is accessed and each instance of the association class identified in the second level 
table is located using defined pointer information (Step 850). 

[065] The CIM Object Manager 340 accesses each association class instance identified 
in the second level wrapper table and references to class instances defined by these association 
class instances are collected (Step 855). This process repeats until there are no more association 
: class instances identified in the second level wrapper table (Step 860). Once every instance in 
! the second level wrapper table has been located and accessed (Step 860; NO), the first level 
wrapper table may be checked to determine whether there any more association classes identified 
in the first level wrapper table that have not been processed (Step 870). If there are more 
association classes, the process may be repeated by returning to Step 820. If no there are no 
;: more association classes to be processed, CIM Object Manager 340 packages the relationship 
information into a response for Java™ VM 330 (Step 880). Java™ VM 330 subsequently 
receives the packaged information and sends it to the client 320 that initiated the request (Step 
890). 

[066] Although Figure 8 shows the process steps associated with the first and second 
level tables being performed in a particular sequence, it is understood that this sequence is 
limiting to the present invention. That is, variations of the sequence of process steps described in 
Figure 8 maybe implemented without departing from the features and principles of the present 
invention. Moreover, the process described in Figure 8 may be modified to accommodate a 
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request to identify a particular object associated with the instance identified in the traversal 
request. That is, the process described in Figure 8 may be modified to accommodate a single 
association class traversal identified in a first level wrapper table. 

[067] As described, methods and systems consistent with features of the present 
invention enables an efficient traversal technique to be implemented by CIM Object Manager 
340 through the use of the wrappers defined in the repository. The process performed by CIM 
Object Manager 340 reduces the processing time and requirements for performing association 
traversals, by accessing the wrapper table associated with a target object. Without the wrappers, 
CIM Object Manager 340 would have to traverse each association to determine the objects that 
have relationships with the target object. 

[068] The wrappers defined in repository 350 are only accessible by CIM Object 
Manager 340. The information within the wrappers is not directly accessible by clients 320 or 
any other remote system. CM Object Manager 340 manages the definitions in repository 350, 
and handles CIM based requests without sharing the data stored within the wrappers. CIM 
Object Manager 340 may use the wrapper information to provide a response to a request, but 
access to the wrappers is not given to any other component. Additionally, the wrappers 
themselves within repository 350 are non-volatile. That is, in the event a failure occurs that 
affects JVM 330, the wrapper tables defined within repository 350 are not lost. In one aspect of 
the invention, the system implementing Java™ VM 330 may include transaction logs that record 
any changes to the wrappers defined in repository 350. Thus, in the event of a failure that affects 
Java™ VM 330, changes to the wrappers may be reinstated by using the transaction log. 

[069] The foregoing description of an implementation of the invention has been 
presented for purposes of illustration and description. It is not exhaustive and does not limit the 
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|, invention to the precise form disclosed. Modifications and variations are possible in light of the 

jl 

1 1 above teachings or may be acquired from practicing of the invention. Additional modifications 

|j 

ij and variations of the invention may be, for example, the described implementation includes 

: software but the present invention may be implemented as a combination of hardware and 

j| software or in hardware alone. The invention may be implemented with both object-oriented and 

jj 

j| non-object-oriented programming systems. 

1 \ 

[070] Furthermore, one skilled in the art would recognize the ability to implement the 

ji present invention using various configurations. For example, where separate tables are 

!| 

|j described, such as shown in Figures 6B and 6C, it is understood that a single table may be used 

1 1 
ij 

ji to store the wrapper table information. Alternately, a single table may be used for first level 
, wrapper table information and a second single table may used for second level wrapper table 

jj information. Also, implementation of well known processing techniques and configurations may 

!| 

j be utilized to facilitate efficient data retrieval. For example, the use of caching techniques may 

! 

ji be used to store frequently requested object information thus further decreasing the time it takes 
to perform a traversal request. Such implementations are within the scope of one skilled in the 
art and may be facilitated using known cache configurations. 

[071] Moreover, it should be understood that the term "reverse link" is only a 
construct to aid in explaining features and principles of the present invention. Reverse links 
represent the relationships between objects and are not to be confused with actual physical 
"connections" between these objects. 

[072] Additionally, although aspects of the present invention are described as being 
stored in memory, one skilled in the art will appreciate that these aspects can also be stored on 
other types of computer-readable media, such as secondary storage devices, like hard disks, 
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floppy disks, or CD-ROM; a carrier wave from the Internet or other propagation medium; or 
other forms of RAM or ROM. The scope of the invention is defined by the claims and their 
equivalents. 
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